home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000015_owner-urn-ietf _Mon Mar 10 15:36:10 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  5KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id PAA15534
  3.     for urn-ietf-out; Mon, 10 Mar 1997 15:36:10 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id PAA15529
  6.     for <urn-ietf@services.bunyip.com>; Mon, 10 Mar 1997 15:36:07 -0500 (EST)
  7. Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA07967  (mail destined for urn-ietf@services.bunyip.com); Mon, 10 Mar 97 15:36:02 -0500
  9. Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id PAA27993; Mon, 10 Mar 1997 15:35:59 -0500
  10. Date: Mon, 10 Mar 1997 15:35:59 -0500
  11. Message-Id: <199703102035.PAA27993@lysithea.lcs.mit.edu>
  12. From: "Karen R. Sollins" <sollins@LCS.MIT.EDU>
  13. To: urn-ietf@bunyip.com
  14. Subject: [URN] semantic representation in URNs
  15. Sender: owner-urn-ietf@Bunyip.Com
  16. Precedence: bulk
  17. Reply-To: "Karen R. Sollins" <sollins@LCS.MIT.EDU>
  18. Errors-To: owner-urn-ietf@Bunyip.Com
  19. Question: should the UDS requirements doc say anything about
  20.  
  21. encouraging or discouraging semantic expression in URNs?
  22.  
  23. Background: The URI group in the past argued about this topic
  24. extensively.  This is part of the discussion about the "user
  25. friendliness" of URNs.  RFC 1737 intentionally only goes as far as
  26. "human transcribable" down this path.  This is really a question about
  27. URNs, more than UDS requirements, although one can imagine that some
  28. designs for a UDS might make be more or less encouraging or
  29. discouraging.  For example (and this is only an example!), consider
  30. hierarchical names and the ordering of elements.  In a completely
  31. general UDS that wanted to make semantics more expressible, ordering
  32. within a subspace might be completely determined by the owner of that
  33. subspace.  Clearly, in order to be able to support certain legacy
  34. naming schemes, we need to all for schemes not to be just
  35. left-to-right or right-to-left.  The question is whether there are
  36. schemes that need to allow for determination in the future of the
  37. ordering of subcomponents and whether future naming schemes
  38. (non-legacy) need this or should have this option.  Even in this
  39. simple example the problem is that in order to allow it, for any UDS
  40. scheme that partitions the problem of resolution along the
  41. hierarchical lines, the local decisions about ordering will require
  42. expression of that in order to walk the hierarchy.  Thus, a statement
  43. that said that no ex post facto ordering choices will be supported
  44. would be one to discourage inclusion of some forms of semantic
  45. expression.
  46.  
  47. The lists of pros and cons below are probably not complete, but I
  48. wanted to give some flavor of the arguments on each side.  Please add
  49. your own and let's get all the issues out on the table.
  50.  
  51.  
  52. CON (discouraging inclusion of semantics):
  53.  
  54. 1) Semantics change with time.  If users become dependent on the
  55. semantics being correct, resources will need to be issued new URNs
  56. when the semantics change and we will have a repeat of all the issues
  57. of URLs.  Remember that one form of semantics is location information,
  58. and if we allow others, we will have the problems in multiple
  59. dimensions.
  60.  
  61. 2) Inclusion of semantics such as in structure may imply more complex
  62. information management in the UDS as described in the background
  63. example above.
  64.  
  65. 3) The hierarchy embodied on URNs reflects namespace delegation.  To
  66. cause that to reflect other semantics as well will be very difficult
  67. in the general case.
  68.  
  69. 4) A URN scheme is extremely unlikely to reflect all the semantics
  70. that might be useful to humans.  Hence human friendly schemes will be
  71. needed on top anyway, and therefore by the end-to-end argument should
  72. not be supported at this level as well.
  73.  
  74. 5) Given the problems with character sets and internationalization,
  75. what is the probability of expressing semantics that would be globally
  76. meaningful.  To allow for translation of semantics to be
  77. internationally meaningful is certainly not part of a UDS.  Without
  78. this, URNs will be meaningful to only part of the customer base at
  79. best anyway.
  80.  
  81. PRO (don't discourage inclusion of semantics or perhaps encourage it):
  82.  
  83. 1) We need to do it for some legacy systems anyway, so why not allow
  84. it for all namespaces.
  85.  
  86. 2) If we are really suggesting using URNs instead of URLs we need
  87. something human friendly now and we don't have anything else.
  88.  
  89. 3) This is a URN issue, not a UDS issue and should not be addressed at
  90. all in the UDS requirements documant.
  91.  
  92. 4) The ability to support semantics does not mean that everyone has to
  93. understand them.  URNs that include semantics might simply be easier
  94. to remember or guess for some parts of the population, but it need not
  95. imply anything about translation of URNs into other things
  96. (e.g. URLs).